Typically, computer programs are designed to execute tasks in the shortest time. Operating systems (OS) are designed to make the best use of the processor capability. Thus, when a program is executed that requires a large amount of data calculation and comparison, the CPU usage rate increases to nearly 100%. If this occurs in a client machine, the response to user accesses at a human interface (input) device (HID) or the like may be delayed, or if this occurs in a server machine, the response to file accesses via a network may be delayed.
To prevent the delay of the response to unexpected external access requests to the CPU resources, the priority level of a thread (a series of tasks that operates independently) belonging to a program process in the task scheduler can be changed to the idle level (the lowest priority level). Alternatively, a program itself can pre-specify the execution priority level in detail to reduce the effect of the program on the CPU usage rate of the entire system. Yet again, the CPU usage rate of the entire system can be measured, and activation of a process then controlled to prevent the CPU usage rate from exceeding a predetermined upper limit.
As understood herein, however, all of these methods have drawbacks. For example, during execution of a program by a computer, it is preferred that the CPU usage rate is effectively controlled, and the delay of response to a user access or a file access is reduced, but simply changing the priority level of a thread, while permitting effective control if the data involved with the process is processed completely in a memory, facilitates less effective controlled if the process involves I/O access to a peripheral device (for example, a process that repeats data comparison and disk I/O, such as an antivirus program). This is because, in the latter case, the I/O waiting time is lengthened, and the task execution time of the main thread is substantially short, so that changing the task priority level of the thread to the idle level (the lowest priority level) does not have a significant effect on the CPU usage rate.
Furthermore, a program that executes a process that involves I/O access to a peripheral device typically repeats I/O accesses without taking into account the presence of other programs. Thus, for example, if a single device, such as a disk I/O, is successively accessed, delays occur in the disk I/Os for other programs and the disk I/O for memory swapping of the OS itself, so that the CPU usage rate is increased in a composite manner.
Still further, in the case where the task priority level of a main thread is changed to the idle level, if data that has not yet read remain in the main thread after completion of the I/O access, the I/O access from another process may not be accepted depending on the design of the OS. In this case, changing the task priority level to the idle level (the lowest priority level) itself can cause an increase of the CPU usage rate.
On the other hand, when the program itself specifies the execution priority level in detail, it is ensured that the effect of the program on the CPU usage rate of the entire system can be reduced. However, it cannot be expected that such an option is implemented on all the programs running on the OS. In addition, since such an option is designed only for the relevant program process, the CPU usage rate of the entire system cannot be controlled if even one program that does not have such an option is executed.
In addition, when the suspension time of a relevant process is calculated from the ratio between the CPU usage rate of the relevant process and the CPU usage rate of the entire system, and the process is suspended temporarily, there is a problem that the calculation of the suspension time takes a certain time, and it is difficult to quickly control the process in response to the actual activation thereof or actual execution state thereof.
With these critical observations in mind, the invention herein is provided.